Objektorientiert/prozedural

Dieser Text beschreibt Objektorientiert/prozedural.

Die Nennung "Objektorientierte Programmierung" (OOP) will sagen, dass es sich gegenüber der herkömmlichen prozeduralen Programmierung um etwas neues, anderes handelt. Für das herkömmliche Verständnis von Computerprogrammierung stehen ja Abläufe, Prozeduren in dem Mittelpunkt, die Befehl für Befehl brav ihre Daten bearbeiten – bis das Ergebnis fertig ist.

Dagegen OOP: neue Arten von Programmteilen (Software-"Objekte") enthalten zusammengepackt (Kapselung) sowohl zugeordnete Daten als "Attribute", und gleichzeitig auch zugeordnete Funktionen als "Methoden", die z. B. mit den Attributen hantieren oder fremde Objekte benutzen, indem sie deren Methoden aufrufen. Hier entsteht das Endergebnis, indem die Objekte sich gegenseitig benutzen.

Programmierer, die sich über Jahre mit gutem Erfolg an das herkömmliche prozedurale Programmieren gewöhnt haben, können vielleicht nicht einsehen, dass es sich wirklich um etwas neues handeln soll. Sie argumentieren etwa, dass die so genannten "Methoden" eines Objektes nichts anderes sind, als ganz gewöhnliche Funktionen, die exakt so mit ihren Daten (– die nun eben Objekt-"Attribute" heißen –) umgehen, wie Funktionen in der prozeduralen Programmierung das auch schon stets gemacht haben. Und wenn es sich in dem Einzelfall wirklich mal als zweckmäßig erweist, bestimmte Daten mit einer bestimmten Funktion zusammenzupacken, dann kann man das in herkömmlichen prozeduralen Sprachen auch so hinorganisieren.

Im Kern ist das nicht ganz falsch. Wo liegt die Wahrheit?

Natürlich kann man in herkömmlichen prozeduralen Programmiersprachen Daten und Funktionen so zusammenpacken, dass ein objektartiges Gebilde entsteht.

Eine erste Besonderheit objektorientierter Programmiersprachen ist, dass dieses "Zusammenpacken" konsequent unterstützt wird. Unterstützt wird außerdem das Hantieren mit dem kompletten Objekt, z. B. das Herstellen einer Kopie, so dass ein zweites Objekt als Klon des ersten entsteht. Auch das könnte man in einer prozeduralen Sprache nachbilden, wenn man weiteren Aufwand treibt. Wenn das ganze Handhabungsverfahren weiter organisch bleiben soll, gehören dazu nun auch noch Verfahren, die die Erzeugung neuer Objekte mit gleichzeitiger Initialisierung unterstützen.

Und wirklich interessant wird OOP dann, wenn auch noch Vererbung möglich ist, wenn also bei der Erzeugung neuer Baumuster (="Klassen") für Objekte die Merkmale einer bewährten Klasse implizit komplett übernommen und für die neue Klasse erweitert werden können – mit wirksamer Software-Unterstützung natürlich. Ebenso sollte man verwandtschaftsbedingte Schnittmengen von Attributen/Methoden unterschiedlicher Klassen in abstrakte Oberklassen verlagern können. Das ganze muss sich dann auch noch schachteln lassen, also beliebig komplexe Objekte können ihrerseits wieder Attribute äußerlich recht einfach strukturierter neuer Objekte sein. Und so ergeben sich nach und nach stets mehr Konsequenzen für eine vernünftige Gesamtgestaltung des Unterstützungsverfahrens.

Konsequent weitergeführt wird sich von einem bestimmten Punkt an zeigen, dass man praktisch eine weitere objektorientierte Programmiersprache mit dem gesamten Implementierungsaufwand hat – auf Basis einer prozeduralen Sprache.

Fazit: Wenn man objektorientiert programmieren will, dann spart es in aller Regel Arbeit, gleich eine fertige objektorientierte Programmiersprache zu benutzen. Und es gibt auch Beispiele dafür, dass zu prozeduralen Programmiersprachen objektorientierte Erweiterungspakete entwickelt werden.

Die Frage, die jeder sich selbst beantworten muss, heißt also: "Ist es für mein Fachgebiet zweckmäßig, objektorientiert zu programmieren?" Während die Kreativität des Programmierers, der eine prozedurale Programmiersprache benutzt, darauf gerichtet ist, geeignete Algorithmen für seine Problemlösung zu finden, muss der Programmierer für eine objektorientierte Sprache seine Kreativität darauf richten, eine Gestaltunsgmöglichkeit für eine kooperierende Population von Objekten zu finden.